Rien de bien fondamental en fait, le principe des paquets reste le même, ce sont des archives tar compressées. Les archives en elles-mêmes ne changent pas du tout, par contre gzip est abandonné au profit de xz.
xz est un nouvel utilitaire de compression, similaire à gzip et bzip2, mais qui emploie l'algorithme LZMA de 7-Zip. Le résultat est sans appel : après conversion, l'arborescence /slackware est passée de 1,9 Go à 1,4 Go, soit une réduction d'environ 25 %.
NdM : OpenSuse utilise déjà LZMA. Fedora commence à fournir un support LZMA. Debian n'a pas encore de paquet xz-utils.
Aller plus loin
- ChangeLog de Slackware (5 clics)
- Site minimaliste de xz (8 clics)
- Article sur LZMA dans Wikipedia (7 clics)
- Gzip (5 clics)
- Bzip2 (3 clics)
- GNU tar (support de la compression xz depuis la version 1.22) (8 clics)
# Woah, la news fondamentale
Posté par Olivier Berger . Évalué à -10.
Vraiment ? ... rien à fou*re !
[^] # Re: Woah, la news fondamentale
Posté par piquouze . Évalué à 10.
[^] # Re: Woah, la news fondamentale
Posté par GEDsismik (site web personnel) . Évalué à 0.
# tar
Posté par Troy McClure (site web personnel) . Évalué à 8.
[^] # Re: tar
Posté par ʭ ☯ . Évalué à 10.
Bref, xz = lzma
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: tar
Posté par herodiade . Évalué à 10.
Voila les specs du nouveau format xz : http://tukaani.org/xz/xz-file-format.txt ; elles indiquent noir sur blanc que ce nouveau format diffère de l'ancien LZMA, entre autres ici :
« This document describes the .xz file format (filename suffix
.xz, MIME type application/x-xz). It is intended that this
this format replace the old .lzma format used by LZMA SDK and
LZMA Utils.
[...]
LZMA2 is an extensions on top of the original LZMA. LZMA2 uses
LZMA internally, but adds support for flushing the encoder,
uncompressed chunks, eases stateful decoder implementations,
and improves support for multithreading. Thus, the plain LZMA
will not be supported in this file format. ».
Concernant la justification de ces divergences/améliorations du format, je cite l'auteur ( source : http://sourceforge.net/forum/forum.php?thread_id=2918394&(...) ):
« The .lzma format is too primitive. It doesn't have an integrity check like CRC32 and it has no magic bytes to make it easy to detect the file type. The .xz format doesn't have these problems. There are some additional features like support for multiple filters (algorithms), filter chaining (like piping on the command line), and limited random-access reading. The .xz format also makes it easier to write multithreaded encoder and decoder. ».
Est-ce que l'un d'entre vous saurait si la parallélisation (le support du « multithread ») de l'encodeur/décodeur est déjà implémentée ?
J'imagine que cette fonctionnalité sera de plus en plus pertinente, dès lors que les CPU x86 vendues de nos jours sont pour la plupart multi-cœurs ou multithreads (avec un nombre de cœurs/threads plutôt en augmentation).
[^] # Re: tar
Posté par Olivier Jeannet . Évalué à 2.
[^] # Re: tar
Posté par Gniarf . Évalué à -4.
[^] # Re: tar
Posté par Antoine . Évalué à 0.
# ca a l'air bien, mais on veut des infos sur xz
Posté par SQP . Évalué à 10.
c'est la première fois que j'entends parler de xz et ça a l'air pas mal, mais quelqu'un sait pourquoi il y a 2 formats différents utilisant le même algorithme ?
si le format 7zip est libre et documenté, je m'interroge sur ce qui a pu motiver à créer un 2e format (ou est il antérieur ?), leur compatibilité, leurs différences, et aussi que je n'ai pas l'air de trouver dans mes dépôts (debian et buntu) contrairement à 7zip. Avoir 2 formats similaires ne peut-il pas devenir gênant ?
voila qd meme quelques petites infos que j'ai pu trouver sur le site xz
# Average compression ratio of LZMA is about 30% better than that of gzip, and 15% better than that of bzip2.
# Decompression speed is only little slower than that of gzip, being two to five times faster than bzip2.
# In fast mode, compresses faster than bzip2 with a comparable compression ratio.
# Achieving the best compression ratios takes four to even twelve times longer than with bzip2. However. this doesn't affect decompressing speed.
petite traduction :
# Le taux de compression de LZMA est amélioré d'environ 30% par rapport à gzip, et 15% pour bzip2.
# Vitesse de décompression est juste un petit peu plus lente que celle de gzip, et 2 à 5 fois plus rapide que bzip2.
# En mode rapide, compresse plus vite, avec un taux similaire à celui de bzip2.
# Obtenir le meilleur taux de compression prend environ 4 à 11 fois plus de temps qu'avec bzip2, mais sans impact sur la vitesse de décompression.
un format sympa destiné à succéder aux vénérables gzip et bzip2, avec un mode rapide pour les usages intenses, et un mode compression maximale très lent, qui ne convient donc pas forcement pour tous les usages, mais qui présente par exemple de gros avantages pour tout ce qui est diffusion par le web, ou pour créer des ISO de distributions (ce qui était apparemment leur but).
Et apparemment au vu des stats annoncées, je pense qu'on devrait voir pas mal de distros suivre le mouvement, pour les dépôts d'archives et les live cd. Les fichiers sont plus petit, donc ca se lit et télécharge plus vite, et ça se décompresse aussi bien plus vite, pour le seul prix d'un temps de compression plus long
[^] # Et pourquoi pas 7z ?
Posté par Dorian . Évalué à 8.
De plus le .7z est un format ouvert et a une certaine notoriété.
« En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll
[^] # Re: Et pourquoi pas 7z ?
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 10.
xz est juste un format de compression. Il est utilisé avec tar pour le contenur de fichiers.
Pourquoi ? Cela permet une compatibilité bien plus facile de tous les outils utilisant des paquets type slackware. Il "suffit" juste de faire une modification pour supporter xz en plus de gzip, pas besoin de toucher à la partie avec tar.
Juste pour nuancer la news, le format .tgz n'est pas abandonné. C'est juste que le format .txz est prioritaire. Les outils de base des distributions slackwares restent quand à eux en .tgz pour une meilleure compatibilité (en tout cas pour l'instant).
À savoir que Slackware a mis à jour la gestion de ses paquets depuis 1 mois et permet de prendre en charge 4 extensions, 3 formats :
- tgz : tar+gzip
- tbz : tar+bzip2
- tlz ou txz : tar+lzma ou tar+xz. Me demandez pas la différence entre les binaires lzma et xz, je sais pas trop (je crois qu'en fait y'en a pas, lzma est l'ancien nom).
Donc Slackware n'abandonne pas le format d'origine, il en rajoute d'autres et change de format par défaut. À savoir que la possibilité de gérer d'autres formats de compression était une demande forte des utilisateurs de Slackware.
Sous Zenwalk, système compatible Slackware, avec gestion de dépendances et plus de paquets, pour l'instant deux formats existent :
- tgz pour la plupart des paquets
- tlz pour les paquets volumineux
Ceci est disponible sur "snapshot", c'est à dire la branche de test. On n'est donc pas à l'abri d'un changement vers .txz pour suivre Slackware...
[^] # Re: Et pourquoi pas 7z ?
Posté par Anonyme . Évalué à 4.
[^] # Re: Et pourquoi pas 7z ?
Posté par B16F4RV4RD1N . Évalué à 6.
Archlinux pourrait envisager de passer également à xz :
http://bbs.archlinux.org/viewtopic.php?id=71896
http://nauseamedialis.org/pacman_meets_lzma
les taux de compressions donnés dans ce lien sont bien supérieurs et donc bien plus intéressants que ceux donnés dans le bench de http://changelog.complete.org/archives/931-how-to-think-abou(...)
D'ailleurs chez moi un test in situ pour une petite archive de 325 ko avec du texte dedans donne une compression de 111 ko pour tgz et 69,3 ko pour tlz ce qui semble très intéressant. (même si cela à mis 0,05 s d'un côté, et 0,5 s de l'autre)
En revanche sur une archive plus grosse de 66 Mo, avec quelques vieux et rares binaires (genre fichiers coreldraw) et le reste contenant des svg, lmza est bien resté bloqué dessus assez longtemps
le résultat est sans appel :
tgz :
real 0m6.462s
user 0m5.760s
sys 0m0.470s
taille : 47,7 Mo
tlz :
real 1m34.955s
user 1m34.164s
sys 0m0.567s
taille : 40,8 Mo
le gain de taille même si moins intéressant que plus haut n'est pas négligeable, mais le temps de compression explose. Quand j'archive (souvent se sont des archives temporaires), la taille n'est pas un problème, en revanche je n'ai pas forcément envie de passer du temps dessus (sauf si c'est un processus automatique, tache cron par exemple)
(bon après il faut voir si ce n'est pas juste les fichiers corel qui ont plombé le petit test)
Comme j'ai dit ailleurs, pour des archivages chez moi je reste à du gzip, pour de la distribution sur internet lmza est plus intéressant.
Pour la décompression de l'archive de 66 Mo :
time tar xf vector.tgz :
real 0m1.919s
user 0m1.033s
sys 0m0.417s
time tar xf vector.tlz :
real 0m6.435s
user 0m5.936s
sys 0m0.437s
pas encore vraiment négligeable dans ce cas...
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Et pourquoi pas 7z ?
Posté par B16F4RV4RD1N . Évalué à 4.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Et pourquoi pas 7z ?
Posté par Octabrain . Évalué à 2.
- Le format 7z ne stocke pas autant de métadonnées (comme le uid du fichier) que tar.
- Dans .tar.gz ou .tar.*, la compression est une étape après l'archivage des fichiers, trop indépendante, qui crée des "archives solides", ce qui rend les modifications de l'archive impossibles (obligé de décompresser, modifier, puis recompresser).
[^] # Re: Et pourquoi pas 7z ?
Posté par rictus (site web personnel) . Évalué à 9.
tar cvf - des_répertoires_ou_fichiers | 7z a -bd -si mon_archive.tar.7z
7z x -bd -so mon_archive.tar.7z | tar tvf -
7z x -bd -so mon_archive.tar.7z | tar xvf -
enfin, mis dans un script, c'est beaucoup plus simple à utiliser. De même 7z est généralement fourni avec un bout de script shell appelé p7zip qui s'utilise de la même manière que gzip. (ex : mysqldump -h localhost --add-drop-table test | p7zip > test.dmp.7z)
Alors oui, on perd l'usage à proprement parlé de conteneur de 7z (un seul fichier compressé dans l'archive 7z). En revanche on gagne des fonctionnalités réimplémentées dans xz (présence de crc par exemple) pour un overhead lié au conteneur à mon avis assez faible. De plus, j'avais observé que 7z tirait bien parti du multicpu (du moins de 2 cpus, au delà, c'est moins vrai) alors que lzma ne gagne rien pour l'instant.
Enfin la commande 7z supporte la plupart des formats (.zip, .gz, .bzip2, .rar ...), ce qui fait un seul outil à connaitre pour tous les formats de compression. (argument faible, mais bon, moi j'aime bien utiliser 7z pour compresser/décompresser des .zip et des .rar)
Bref, selon moi, 7z, c'est libre, c'est multi-plateforme, c'est bon, mangez-en !
Nota : mon commentaire n'a pas vocation à critiquer xz/lzma, mais seulement à flatter p7zip...
[^] # Re: Et pourquoi pas 7z ?
Posté par Kerro . Évalué à 8.
[^] # Re: Et pourquoi pas 7z ?
Posté par rictus (site web personnel) . Évalué à 2.
--use-compress-program PROG
filter the archive through PROG (which must accept -d)
Ok, donc à utiliser avec le shell p7zip (qui implémente le -d).
tar --use-compress p7zip -cvf toto_dir toto.tar.7z
tar --use-compress p7zip -xvf toto.tar.7z
Testé, ça marche (tm).
alias ztar='tar --use-compress-program p7zip'
Donc encore un argument encore pour 7z ... ;-)
[^] # Re: Et pourquoi pas 7z ?
Posté par Kerro . Évalué à 3.
Ca dépend fortement de ce qu'on a à compresser.
Mes exports+sauvegardes MySQL par exemple sont mieux compressés avec bzip2 qu'avec 7zip (1,1 Go actuellement). Et c'est également plus rapide avec bzip2, genre moitié moins de temps. J'ai le même résultat avec la sauvegarde de pages web (quelques Mo). Et encore la même chose pour la sauvegarde de disques virtuels Windows (1,5 To chaque nuit).
note: c'est sous Debian Etch, avec les paquets d'origine. Il y a peut-être des améliorations significatives depuis, bien que l'énorme différence que j'ai trouvé en faveur de bzip2 ne me le laisse pas présager.
Le top reste LZO qui compresse nos flux VPN. Ca prends presque zéro en processeur, et ça compresse tout de même largement assez bien pour ce qu'on en fait.
[^] # Re: Et pourquoi pas 7z ?
Posté par rictus (site web personnel) . Évalué à 3.
bench rapide sur un petit dump mysql :
time lzop 20090512-035301.dmp
real 0m0.221s
user 0m0.176s
sys 0m0.040s
time gzip 20090512-035301.dmp
real 0m1.123s
user 0m1.048s
sys 0m0.024s
time bzip2 20090512-035301.dmp
real 0m4.808s
user 0m4.784s
sys 0m0.024s
time p7zip 20090512-035301.dmp
real 0m8.066s
user 0m8.697s
sys 0m0.268s
time lzma 20090512-035301.dmp
real 0m14.958s
user 0m14.429s
sys 0m0.144s
test sur un bi-pro au repos... p7zip tire bien partie des deux cores.
Pour la taille, par contre, je suis surpris que tu aies observés des cas de bzip2 meilleurs que 7z :
(note, j'ai vraiment pris le dump au hasard, mais j'ai pas non plus cherché de contre exemple)
1406545 20090512-035301.dmp.lzma
1559779 20090512-035301.dmp.7z
1768026 20090512-035301.dmp.bz2
2153230 20090512-035301.dmp.gz
3238305 20090512-035301.dmp.lzo
13195637 20090512-035301.dmp
lzma sans doute significativement plus petit par rapport à 7z pour les motifs évoqués au-dessus : sans doute pas de crc, et pas d'entête non plus gérant l'enveloppe.
Désolé, j'ai pas xz pour tester.
[^] # Re: ca a l'air bien, mais on veut des infos sur xz
Posté par M . Évalué à 10.
si le format 7zip est libre et documenté, je m'interroge sur ce qui a pu motiver à créer un 2e format (ou est il antérieur ?),
De memoire la difference entre 7zip et xz est la même qu'entre zip et gzip.
7zip comme zip ne font pas que de la compression mais aussi de l'archivage (ce que fait tar).
Je pense que c'est la philosophie UNIX (chaque outil fait un seul truc) qui a amené a la modification du format.
[^] # Re: ca a l'air bien, mais on veut des infos sur xz
Posté par Troy McClure (site web personnel) . Évalué à 0.
Ah oui, celle qui fait que que ça prends des siècles pour lister le contenu d'une archive tar compressée parce que justement la partie compression est une surcouche bourrine au-dessus du format d'archive
[^] # Re: ca a l'air bien, mais on veut des infos sur xz
Posté par totof2000 . Évalué à -10.
Si ça te plais pas retourne sous winzip ...
[^] # Re: ca a l'air bien, mais on veut des infos sur xz
Posté par Troy McClure (site web personnel) . Évalué à 3.
[^] # Re: ca a l'air bien, mais on veut des infos sur xz
Posté par djibb (site web personnel) . Évalué à 8.
[^] # Re: ca a l'air bien, mais on veut des infos sur xz
Posté par X345 . Évalué à 10.
[^] # Re: ca a l'air bien, mais on veut des infos sur xz
Posté par Barnabé . Évalué à -1.
Maintenant, je ne comprend pas très bien ce que tu viens faire ici si cette philosophie ne te plait pas.
[^] # Re: ca a l'air bien, mais on veut des infos sur xz
Posté par Troy McClure (site web personnel) . Évalué à 3.
[^] # Re: ca a l'air bien, mais on veut des infos sur xz
Posté par Larry Cow . Évalué à 10.
[^] # Re: ca a l'air bien, mais on veut des infos sur xz
Posté par Barnabé . Évalué à -3.
[^] # Re: ca a l'air bien, mais on veut des infos sur xz
Posté par Azollyx Horaldius (site web personnel) . Évalué à 2.
Tu fais bien quelque chose du genre
tar -tzvf monarchive.tar.gz
pour lister ?
Faire
gunzip monarchive.tar.gz | tar -tv
est certainement très long mais pour la méthode précédente je trouve ça correct.
(Ceci, je ne l'utilise pas très souvent... du tout. :D)
[^] # Re: ca a l'air bien, mais on veut des infos sur xz
Posté par benoar . Évalué à 5.
[^] # Re: ca a l'air bien, mais on veut des infos sur xz
Posté par campagnard . Évalué à 3.
[^] # Re: ca a l'air bien, mais on veut des infos sur xz
Posté par Troy McClure (site web personnel) . Évalué à 4.
(Tout ceci est cependant une spéculation, si jamais le club des experts de tar veut me corriger ils sont les bienvenus)
[^] # Re: ca a l'air bien, mais on veut des infos sur xz
Posté par nicoastro . Évalué à 2.
[^] # Re: ca a l'air bien, mais on veut des infos sur xz
Posté par Barnabé . Évalué à 3.
Ma solution serait d'adjoindre à l'archive compressée un index du contenu. Ca se fait en 3 scripts basiques (un pour archiver, un autre pour lister et le troisieme pour extraire) ou bien en un script a peine plus chiadé qui devra gerer les options en ligne de commande et appeler tar.
Ceci dit, la lenteur de tar sur le listage d'un gros fichier ne m'a pas souvent géné.
[^] # Re: ca a l'air bien, mais on veut des infos sur xz
Posté par patrick_g (site web personnel) . Évalué à 8. Dernière modification le 19 octobre 2023 à 17:46.
A noter que le fait de compresser individuellement pleins de petits fichiers ou un seul gros fichiers peut changer radicalement les résultats.
Cela semble logique car l'algo peut trouver plus de redondances compressables dans le gros fichier.
Je m'en suis aperçu quand j'ai voulu proposer une archive des nouvelles de SF sur mon site. Il s'agit de pleins de petits fichiers html (plus de 1300) et ils contiennent donc pas mal de choses communes puisque la mise en page est toujours identique.
Tu peux voir les résultat sur https://patrickguignot.fr/sf/introduction_sf.html
nouvelles_sf.zip (2,2 Mo)
nouvelles_sf.tar.bz2 (274 Ko)
L'écart est monstrueux !
[^] # Re: ca a l'air bien, mais on veut des infos sur xz
Posté par Thomas Douillard . Évalué à 3.
[^] # Re: ca a l'air bien, mais on veut des infos sur xz
Posté par patrick_g (site web personnel) . Évalué à 2.
On voit donc que l'algo bz2 est meilleur intrinsèquement que l'algo zip (274 Ko contre 410 Ko) mais surtout que la manière de procéder de zip (compresser d'abord et rassembler ensuite) est inefficace puisque dans ce cas on obtient un fichier de 2.2 Mo en sortie.
# lien / comparatif des formats de compression libres
Posté par Anonyme . Évalué à 10.
http://changelog.complete.org/archives/931-how-to-think-abou(...)
Cela me semble complet et la procédure de test pertinente.
[^] # Re: lien / comparatif des formats de compression libres
Posté par Farfouille . Évalué à 9.
Je pense en particulier à des LiveCD de systèmes légers qui peuvent fonctionner avec moins de 64Mo de RAM, mais incapables de se lancer car la décompression des fichiers en lzma nécessite plus de 128Mo de RAM...
[^] # Re: lien / comparatif des formats de compression libres
Posté par Farfouille . Évalué à 10.
http://tukaani.org/lzma/benchmarks
"The memory usage of lzma stays competitive with bzip2 when files have been compressed with "lzmash -6" or with a smaller option. The files compressed with the default "lzmash -7" can still be decompressed, even on machines with only 16 MB of RAM, but sometimes you don't have even that much memory available. If you compress with "lzmash -8" or "lzmash -9", you should think if the users need to be able to decompress your files also on "ancient" computers."
[^] # Re: lien / comparatif des formats de compression libres
Posté par M . Évalué à 5.
il est existe des versions optimisé de lzma pour l'embarqué (lzma dans busybox (qui est celle dans le noyau linux), XZ Embedded, ...)
On t elle les meme propriété que ce qui a ete observé dans ce bench ?
[^] # Re: lien / comparatif des formats de compression libres
Posté par vladislav askiparek . Évalué à -1.
Bon dimanche.
[^] # Re: lien / comparatif des formats de compression libres
Posté par B16F4RV4RD1N . Évalué à -2.
Bref, peut-être que c'est bien pour créer les paquets d'une distribution utilisée par des dizaine de millions (rhmmm) d'utilisateurs, mais pour chez moi je garde gunzip.
De plus je ne vois pas l'intérêt de ce format xz par rapport à 7z
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: lien / comparatif des formats de compression libres
Posté par Gniarf . Évalué à 1.
[^] # Re: lien / comparatif des formats de compression libres
Posté par B16F4RV4RD1N . Évalué à 10.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: lien / comparatif des formats de compression libres
Posté par B16F4RV4RD1N . Évalué à 10.
Le sujet de #linuxfr est : http://www.linuxfr.org/ - ISO8859-15 UNIQUEMENT (pas d'utf8)(trop pas)(les contestataires on les fusille)
* Sujet de #linuxfr défini par Gniarf le Wed Oct 1 00:19:08 2008
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: lien / comparatif des formats de compression libres
Posté par yellowiscool . Évalué à 4.
Envoyé depuis mon lapin.
[^] # Re: lien / comparatif des formats de compression libres
Posté par windu.2b . Évalué à 10.
(mais c'est normal : c'est une appli KDE ! Y a donc 3927 réglages/cm² d'IHM ;-)
[^] # Re: lien / comparatif des formats de compression libres
Posté par FlashCode (site web personnel, Mastodon) . Évalué à 2.
WeeChat, the extensible chat client
[^] # Re: lien / comparatif des formats de compression libres
Posté par Olivier Jeannet . Évalué à 2.
[^] # Re: lien / comparatif des formats de compression libres
Posté par modr123 . Évalué à 4.
After: kernel-source-2.6.29.2_smp-noarch-1.txz (49150104 bytes)
The size of the main package tree in /slackware has been reduced from
1.9GB to 1.4GB by converting most packages to .txz.
lu dans le changelog
[^] # Re: lien / comparatif des formats de compression libres
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 10.
George Vlahavas avait fait quelques tests pour Zenwalk lors du support des différents formats de compression par Slackware :
Donc xz/lzma est bien pour un système de paquets où ce qui importe le plus est la taille et le temps de décompression plus que le temps pour créer le paquet.
# Evolution logique
Posté par ʭ ☯ . Évalué à 8.
Chez Mandriva, je me souviens que la migration, proposée en 2008, ne s'est pas faite car le temps de compression a été jugé trop lourd. Probablement le temps qu'ils aient de nouveaux CPU ;-)
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Evolution logique
Posté par Spyhawk . Évalué à 5.
http://en.opensuse.org/LZMA
Outre le fait que les téléchargements sont plus petits et les medias plus fournis grace a la meilleure compression, la décompression de ces derniers est également meilleure, d'ou une installation plus rapide (d'un facteur 2.5 dans certains cas). Le Build Service morfle cependant un peu plus, mais ils ont de la marge.
Il aussi probable que le format des metadatas utilisé par le gestionnaire ZYpp passe à LZMA dans un futur plus ou moins proche (voir le récent billet http://duncan.mac-vicar.com/blog/archives/537 )
[^] # Re: Evolution logique
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
$ ll loopbacks/distrib-lzma.sqfs
-rwx------ 1 root root 705523712 2009-04-24 17:34 loopbacks/distrib-lzma.sqfs*
C'est aussi utilisé depuis quelque temps dans les man, par exemple, "man cp" utilise : /usr/share/man/fr/man1/cp.1.lzma
# lzma/xz ?
Posté par 태 (site web personnel) . Évalué à 4.
Parmi les autres gestionnaires de paquets pour linux ou autres, macports supporte lzma (sait utiliser les paquets sources au format lzma) depuis la version 1.7.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.